In computer programming, an ever increasing number of resources are becoming available on networks, e.g., local networks or the Internet. This is shifting the philosophy of software development from tightly coupled applications, in which different applications are capable of accessing each other to obtain required information, to more loosely coupled service-oriented architectures (SOAs) based on software components called services, which are typically designed to perform a specific (single) task and to be reused in many different (client) applications. In a SOA, a service is typically requested to produce a deliverable, e.g., the completion of a task, information, and so on, by requests or messages. Most services are typically designed to perform specific tasks upon request. A typical architecture is shown in FIG. 1. A service registry 100 acts as a directory of available services 120, which have registered with the service registry 100. A service consumer or client 140 can contact the service registry 100, either directly or via a proxy server (not shown), in order to locate services 120 that can be integrated in a business application of the client 140, such that the application can directly contact the service 120 and the service can directly deliver the requested service to the client 140.
Such a service-based approach to application design is extremely promising in terms of design flexibility, as a designer of a client application does not need to know how a particular (remote) service has been designed; it suffices to know how the service needs to be requested and what the service is capable of delivering. Service requests are typically formulated and handled using standardized message protocols, e.g., an XML-based protocol such as SOAP or JSON.
A particular challenge when designing or configuring an application that at least in part relies on services for its functionality is how to locate a service that can perform a desired task. In the conventional service registry system 100, to discover a service description 122 during development of a software system, a programmer of the software system needs to know a service name 121 in order to identify the service description 122. To this end, protocols such as WS-Discovery are available that allow a client to search for one or more target services over a (local) network, e.g. by accessing the service registry 100 in which the services are registered and provide the service registry 120 with a target system name 121. Such protocols may involve communicating with a central registry or issuing a multicast communication of a request for services to a group of services, in which the name of the requested service has to be specified. Services that match this name will respond to such communications, thereby informing the client of that a matching service is available on the network.
It will be immediately apparent that this requires the client to have a priori knowledge of the name of the desired service, which more often than not is not the case, such that it is difficult in practice to locate a desired service. Although a find_service operation to find a service is available in the Universal Description, Discovery, and Integration (UDDI) interface of the conventional service registry system 100, the find_service operation is impractically difficult to use for the programmer while developing the software system. This seriously hampers the deployment of SOAs.